-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correctly normalize package names. Fixes #2956 and #3002 #3008
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a bunch for identifying this (we will need a patch for it, but this is the last bit of the vendoring process that is somewhat involved, so I can take care of it and/or automate it if we do merge it)
Overall I'm not too sure if we do want to go this route, patching pip directly to fix this. I am reasonably confident this is only working incorrectly for the index, so this is probably the relevant patch. I will want to solicit some input before making a call on this one
@@ -766,7 +766,7 @@ def egg_info_matches( | |||
return full_match[full_match.index('-'):] | |||
name = match.group(0).lower() | |||
# To match the "safe" name that pkg_resources creates: | |||
name = name.replace('_', '-') | |||
name = name.replace('_', '-').replace('.', '-') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^_^ I am actually tempted to do this, but I have a preference for not patching pip whenever possible.
I'm likely going to hold off on accepting this for the next release to see about getting feedback from the pip maintainers when I have a bit more clarity on all of the places we are currently working around this problem, which I think is pretty numerous by now...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's up to you if you accept it, and I understand if you do not, but this is currently breaking our (am I am sure others) workflow entirely. I can't see a workaround apart from downgrading
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@orf, apart from the issues mentioned and the fixes for those specifically (which are in master), can you describe what is continuing to cause you problems? I.e. with the current master branch, how do I see a problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will get back to you here tomorrow morning, after I try installing the specific pipfile I have with the current master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I see the issue in question. This should be resolved by #3007
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Thanks for your continued work on pipenv, and I'm sorry for the volume of issues!
I will confirm tomorrow that this is fixing it, or though I cannot see any code that would after my brief lookm
/cc @pradyunsg, @cjerdonek (don't want to bother paul since I know he is taking time off) tl;dr package name normalization isn't fully pep 503 compliant when being handed off to the index lookup in pip, we have a bunch of workarounds right now but this PR is proposing a patch to our vendored pip version. Any thoughts about whether this is intentional or an oversight? We can push this upstream if desired |
@techalchemy I don't know much about this aspect of pip. Note that @uranusjr just opened this PR which touches this very code: pypa/pip#5875 |
We don't even communicate that well when we are co-maintainers of the same projects
Just read the full PR, I think he does capture this, he probably already saw / encountered it and just upstreamed it |
Yeah, I figured that might have been happening so wanted to be sure you were at least alerted here! |
To make sure, is pypa/pip#5875 required to fix this? I was assuming it is worked around by 59dd901#diff-2c68dad4d149b80846780635fda149f2 |
@uranusjr nope, as far as I understand we don't need that change for this to work |
closing for now since we will catch this upstream in the next release of pip, thanks for the PR and thanks for the input all |
Fixes #2956 and #3002